Authorization and authentication for recurring workflows

ABSTRACT

An approval request for a recurring workflow instance is received, that requests the execution of an instance of a recurring workflow. An authorization token is generated based upon the content of the particular workflow to be executed, the location where the workflow is to be executed, and a time period during which the workflow is to be executed. The authorization token is sent, along with a representation of a workflow to be executed, to a target machine for authorization and execution.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is based on and claims the benefit of U.S.provisional patent application Ser. No. 62/610,676, filed Dec. 27, 2017,the content of which is hereby incorporated by reference in itsentirety.

BACKGROUND

Computing systems are currently in wide use. Some such computing systemsare housed in data centers which include a facility that houses variouscomputer systems and other components, such as communication componentsand data storage systems. Data centers normally include computingsystems that may be used by organizations for the remote storage,processing, and/or distribution of large amounts of data.

In order to manage and maintain the computing systems and the physicalmachines in a data center, many different types of workflows run in adata center. A large number of these workflows are recurring workflows.Some of the recurring workflows are authorized by a human being, whileothers are authorized automatically.

Recurring workflows can take a wide variety of different forms. Many ofthem, however, are background jobs that run on the data center andcollect information about the health of the data center computingsystems and machines. For instance, some recurring workflows may collectdata or various metrics that characterize the health of the servicesrunning on the computing system. Others may collect data (such as aphysical temperature of the hardware machines) that are used to monitorthe physical health of the hardware machines in the data center. Stillothers can include certain destructive operations, such as thedeployment of new bits, disk cleanup operations and/or routerrestamping.

In some current systems, an instance of a recurring workflow isauthorized in a way that may not be closely related to the particularworkflow to be executed. Therefore, if a surreptitious user obtainsaccess to the authorization mechanism (e.g., a token), the surreptitioususer may be able to replace the authorized workflow with a surreptitiousworkflow to gain access to various components within the data center.

The discussion above is merely provided for general backgroundinformation and is not intended to be used as an aid in determining thescope of the claimed subject matter.

SUMMARY

An approval request for a recurring workflow instance is received, thatrequests the execution of an instance of a recurring workflow. Anauthorization token is generated based upon the content of theparticular workflow to be executed, the location where the workflow isto be executed, and a time period during which the workflow is to beexecuted. The authorization token is sent, along with a representationof a workflow to be executed, to a target machine for authorization andexecution.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter. The claimed subject matter is not limited to implementationsthat solve any or all disadvantages noted in the background.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of one example of a computing systemarchitecture.

FIG. 2 is a block diagram showing one example of a recurring workflowgeneration system in more detail.

FIG. 3 is a flow diagram illustrating one example of the operation ofthe architecture illustrated in FIGS. 1 and 2.

FIG. 4 is a flow diagram illustrating one example of the operation ofthe architecture in generating an authorization token and a signedmanifest, in more detail.

FIG. 5 is a flow diagram illustrating one example of the operation of anauthorization worker system in authorizing a received request to executean instance of a recurring workflow.

FIG. 6 shows the computing system architecture illustrated in FIG. 1,deployed in a cloud computing architecture.

FIG. 7 is a block diagram showing one example of a computing environmentthat can be used in the architectures shown in the previous figures.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of one example of a computing systemarchitecture 100. In the example illustrated in FIG. 1, architecture 100illustratively includes a set of workload computing systems 102-104 thateach correspond to a different computing system environment. Forinstance, workload computing system 102 corresponds to environment Awhile workload computing system 104 corresponds to environment N. Theenvironments can be defined in a variety of different ways. In oneexample, the environments may be different geographical locations of thedifferent computing systems (i.e., the particular data center in whichthey reside). In another example, an environment may be defined by theparticular service that it is rendering (such as an e-mail service, aconferencing service, a calendaring service, etc.). In yet anotherexample, the environment may be defined by the identity of a particularset of physical hardware servers or machines that are providing aservice.

FIG. 1 also shows that the workload computing systems 102-104 arecoupled to a management computing system 106 and anauthentication/authorization computing system 108 over network 110.Network 110 can be a wide area network, a local area network, a nearfield communication network, a cellular communication network, or a widevariety of other networks or combinations of networks.

Each workload computing system 102-104 illustratively includes a set ofcapacity servers 112-114 (in system 102), and 116-118 (in system 104).One or more of the capacity servers in each computing system can includean authorization worker system 120, and other capacity serverfunctionality 122. Computing systems 102 and 104 can also include a widevariety of other items 124-126, respectively. The capacity servers112-118 illustratively provide the various services that are offered bytheir corresponding computing systems. The services can include a widevariety of different types of services. The capacity servers can also beused to run background jobs, such as maintenance workflows, monitoringworkflows, or a wide variety of other different types of workflows. Someof these workflows will be recurring workflows, in that they will berepeated on a periodic or intermittent basis.

In the example illustrated in FIG. 1, authentication/authorizationsystem 108 illustratively includes one or more processors or servers128, token/manifest processing system 131, and it can include a widevariety of other authentication/authorization functionality 132.

Management computing system 106 can also include one or more processorsor servers 134, a certificate management system 136, recurring workflowgeneration system 130, and it can include a wide variety of otherfunctionality 138. Recurring workflow generation system 130illustratively includes workflow instance generator logic 141, approvalrequest generator logic 145, data store 154 and it can include otheritems 146. Certificate management system 136 can include a certificateauthority, a certificate service, or a wide variety of other componentsthat manage the generation and transmission of certificates that can beused in authenticating and authorizing workflows in architecture 100.Data store 154 (which is shown in management system 106 by way ofexample only, and could be located elsewhere or split among varioussystems) illustratively includes a set of pre-scheduled, pre-configuredworkflows 158, workflow definition configuration files 160,requestor/worker reference mappings 162, and it can include other items164. The pre-scheduled workflows 158 illustratively identify whencertain recurring workflows are to be executed. The workflow definitionconfiguration files 160 illustratively identify what particularworkflows are to be executed and where they are to be executed.

It may be, that a requestor who is requesting a workflow to be executed,and the authorization worker system 120 that is going to authorize andexecute the workflow, refer to the workflows in different ways. Forinstance, authorization worker system 120 may refer to the particularworkflow by its script or workflow content. The requestor side(recurring workflow generation system 130) may refer to the workload bya name Similarly, the authorization worker system 120 may identify thelocation where the workflow is to be executed using the specificidentity of different physical machines on which system 120 runs (or onwhich the workflow is to be executed). However, recurring workflowgeneration system 130 may refer to the location by the environment, by aservice instance type being run by the environment, or in other ways.

Therefore, requestor/worker reference mappings 162 illustrativelyinclude a set of mappings that map between the way the different itemsin architecture 100 refer to the workflow itself and to the locationwhere the workflow is to be executed. Thus, it can include a set ofindividual workflow reference mappings 166 that map from a strong name168 to a script/workflow identity 170. It can also include a locationmapping that maps from a scope 172 to a machine identity 174. The strongname may be generated in a variety of different ways. For instance, itcan include a globally unique identifier (GUID) defined for the scriptalong with a friendly name that may be recognizable to a human, alongwith a secondary GUID (such as a project GUID). This combination (orother combinations) of items ensure that each workflow is uniquelyidentifiable by its strong name.

As an overview, recurring workflow generation system 130 illustrativelymonitors when recurring workflows are to be executed, and generatesworkflow instances for those recurring workflows. This is described ingreater detail below. Briefly, however, it illustratively identifies theparticular workflow that is to be executed as well as the targetenvironment (and possibly individual machines) where the workflow is tobe run. It identifies a time period over which the workflow is to beexecuted. Approval request generator logic 145 halts the execution ofthe recurring workflow instance and sends an approval request toauthentication/authorization system 108. Approval logic 142 obtainsmanual or automatic approval to execute the recurring workflow (based onconfiguration) and token/manifest processing system 131 generates anauthorization token. It packages the workflow script and/or binary listin a manifest and it includes the authorization token. It signs themanifest with an environment-specific certificate and sends it back torecurring workflow generation system 130. The manifest and workflowinstance are then sent to the particular workload computing system(e.g., workload computing system 102) where the recurring workflow is tobe executed. Authorization worker system 120 on workload computingsystem 102 then authorizes the workflow by determining whether theincluded authorization token corresponds to the workflow script orbinary list that is to be executed and that is included in the manifest.It also determines whether the environment-specific signing certificateused to sign the manifest corresponds to the environment where themanifest was received.

Authorization worker system 120 illustratively performs a relativelyfine-grained authorization by determining whether the authorizationtoken included in the manifest authorizes the particular workflowinstance to be executed (i.e., whether it authorizes the operations thatare to be performed) that is also included in the manifest. Itdetermines whether the token authorizes the location where theoperations are to be performed (e.g., the environment, set of targetservers, etc. that are to execute the operations in the recurringworkflow), and it determines whether the token authorizes the timeperiod during which the operation is to be performed (e.g., when theoperations are to be performed). Only if the requested workflow isauthorized in this way, will it be executed.

This greatly enhances the security of computing system architecture 100.For instance, even if a surreptitious user obtains access to theauthorization token, that authorization token only authorizes theparticular workflow that it was intended to authorize. It onlyauthorizes that particular workflow at the location (e.g., on theidentified set of target machines) that is intended to run it, and itonly authorizes that workflow, on those machines, during a time periodwhen the workflow was intended to be executed. This inhibits asurreptitious user from obtaining an authorization token and thensubstituting a surreptitious workflow for the intended workflow.

FIG. 2 is a block diagram showing one example of token/manifestprocessing system 131 in more detail. In the example illustrated, system131 illustratively includes token generator logic 148, manifestgenerator logic 150, manifest signing logic 152, and it can include awide variety of other items 156.

By way of overview, in operation, recurring workflow instance generatorlogic 141 illustratively accesses the record of the pre-scheduledworkflows 158 to determine whether a recurring workflow is to beexecuted within architecture 100. It generates an instance of therecurring workflow. It then uses approval request generator logic 145 tohalt execution of that workflow, and to generate an approval request,which is sent to approval logic 142 to obtain any approval that isneeded to run the recurring workflow. If the approver is a humanapprover, then an approval request will be sent by logic 142 to theapprover in order to obtain approval to run the recurring workflow. Ifit is an automated approver, then the approval logic 142 will generatean approval request to the automated system that provides the approval.Once approval is received, token generator logic 148 illustrativelygenerates an authorization token based upon the workflow itself, thetarget location where the workflow is to be executed, and the timeperiod during which it is to be executed. Manifest generator logic 150generates a manifest that includes the workflow script or binary list,itself, along with the authorization token. Manifest signing logic 152illustratively signs the manifest with an environment-specific signingcertificate. The signed manifest 180 (which includes the workflow itselfalong with the authorization token, which are signed using theenvironment-specific signing certificate) is then sent back to recurringworkflow generation system 130 in management computing system 106, whichmay include one or more additional certificates for authorizing thesinged manifest 180. System 130 then continues with execution of therecurring workflow instance on the workload computing system 102-104where it is to be executed, using the authorization token and signedmanifest 180.

FIG. 3 is a flow diagram illustrating one example of the overalloperation of architecture 100 shown in FIG. 1 in authorizing andexecuting a recurring workflow. Workflow instance generator logic 141first determines that a pre-scheduled, recurring workflow is to beexecuted. It then generates an instance of that recurring workflow forexecution. Generating the recurring workflow instance for approval isindicated by block 200 in the flow diagram of FIG. 3. Approval requestgenerator logic 145 generates an approval request and sends it toauthentication/authorization system 108. This is indicated by block 201.

Approval logic 142 then identifies, based upon a workflow definitionconfiguration file 160 for the pre-scheduled (which may be separatelyaccessed by logic 142 or sent along with the approval request),recurring workflow (or in another way), what type of approval, if any,is needed for execution of the recurring workflow. It then notifies theapprover, and receives approval for the execution request. This isindicated by block 202 in the flow diagram of FIG. 3. It can identifythe approver using role-based access control data that may be found onthe definition of the workflow set out in the workflow definitionconfiguration file 160, corresponding the recurring workflow to beexecuted. This is indicated by block 204. The approval can be from aperson or automated, and it can be carried out in a wide variety ofother ways as well, and this is indicated by block 206.

Once approval for execution of the recurring workflow instance isobtained, token generator logic 148 generates a fine-grainedauthorization token, and manifest generator logic 150 generates amanifest for the single recurring workflow instance. This is indicatedby block 208 in the flow diagram of FIG. 3. In one example, thefine-grained authorization token is generated based upon the identity ofthe workflow (e.g., the script for the workflow, the name of theworkflow, another representation of the workflow such as a hash of theworkflow, etc.), the identity of the location where the workflow is tobe executed (such as a set of target servers, an environment, etc.), anda time period over which the recurring workflow is to be executed.Generating the fine-grained authorization token based upon the workflow,the location where it is to be executed and the time when it is to beexecuted is indicated by block 210 in the flow diagram of FIG. 3.Manifest generator logic 150 identifies the particular workflow to beexecuted by accessing the workflow definition configuration file 160, orin other ways and adds it to the manifest. The manifest can include thetoken as well as a representation of the content of the workflow itself(such as the script, binary list, etc.). Generating the fine-grainedauthorization token and manifest can be done it a wide variety of otherways as well, and this is indicated by block 212. One example forgenerating the authorization token and manifest is described in greaterdetail below with respect to FIG. 4.

The manifest is then signed as well by manifest signing logic 152. Thesigning certificate is illustratively specific to the environment wherethe workflow will be executed.

Once the signed manifest 180 is generated and signed, it is sent back toworkflow instance generator logic 141 where it can be used, along withthe generated instance of the recurring workflow, for execution on a setof target servers. This is indicated by block 214 in the flow diagram ofFIG. 3. In one example, it can be sent through management computingsystem 106 to the particular environment where the target serversreside.

An authorization worker system 120, on one of the target servers,authorizes the execution request represented by the signed manifest 180using the authorization token that is included in the signed manifest180. This is indicated by block 216 in the flow diagram of FIG. 3.Because the authorization token is generated based on the workflowitself, the location where it is to be executed and the time when it isto be executed, the authorization worker system 120 authorizes theworkflow itself, using the token. This is indicated by block 218. Itauthorizes the location where the workflow is to be executed, based uponthe token. This is indicated by block 220. It also authorizes the timeperiod when the workflow is to be executed. This is indicated by block222. Authorization can be done in a wide variety of other ways as well,and this is indicated by block 224.

The authorization worker system 120 determines whether the request isfully authorized (as to the workflow, location, and time). This isindicated by block 226. If not, a message is generated indicating thatan unauthorized workflow has been sent to the target environment forexecution, and the workflow is not executed. This is indicated by block228. However, if, at block 226, the workflow is fully authorized, thenthe capacity server or set of target servers execute the recurringworkflow. This is indicated by block 230 in the flow diagram of FIG. 3.

FIG. 4 is a flow diagram illustrating one example of the operation oftoken generator logic 148, manifest generator logic 150 and manifestsigning logic 152 in generating the authorization token and themanifest, and in signing the manifest 180. It is assumed that therecurring workflow instance has been generated and any approval that isneeded has been obtained.

Token generator logic 148 then accesses a pre-defined configuration file160 (which can reside on system 106 or 108 or elsewhere) for therecurring workflow that is to be executed. This is indicated by block240 in the flow diagram of FIG. 4. It identifies, from thatconfiguration file, a set of target servers that the workflow will runon. This is indicated by block 242. The set of target servers can beidentified in a variety of different ways. The token generator logic 148also identifies, from the configuration file, the particular workflowthat will be called on the set of target servers when the recurringworkflow is executed. This is indicated by block 244. The particularworkflow can be identified by a strong name 246, as described above. Itcan also be identified using a hash value 248, which may be a hash valuegenerated from the workflow script, or otherwise representing theworkflow. The workflow can be identified in a wide variety of other ways250 as well.

Token generator logic 148 also identifies a time period over which theworkflow is expected to run, or be executed, on the target servers. Thisis indicated by block 252. It then generates a payload authorizationtoken based upon the target servers, the workflow itself, and theidentified time period. This is indicated by block 254. Because theauthorization token is generated based upon these relativelyfine-grained values, even if the token itself is surreptitiouslyobtained, it can only be used to authorize the desired workflow, at thedesired target servers, during the desired time period.

Once the token is generated, manifest generator logic 150 generates themanifest by including, in the manifest, the authorization token, as wellas a representation of the workflow that is to be executed. Therepresentation of the workflow can be the workflow script, a binary listcorresponding to the workflow, or another representation which can beused to execute the workflow. Generating the manifest 180, including theauthorization token and a representation of the workflow, is indicatedby block 256 in the flow diagram of FIG. 4.

Manifest signing logic 152 then accesses an environment-specific signingcertificate. These certificates can be stored, for instance, in a datastore on system 108, data store 154 and indexed by environment. They canbe dynamically generated or stored elsewhere as well. Manifest signinglogic 152 then signs the manifest 180 with the environment-specificsigning certificate. Accessing the environment-specific signingcertificate is indicated by block 258 and signing the manifest with thatcertificate is indicated by block 260.

In this way, only an authorization worker system 120 on the environmentwhere the workload is intended to be executed, will authorize the signedmanifest. This provides additional security.

FIG. 5 is a flow diagram illustrating one example of the operation ofauthorization worker system 120 in authorizing a recurring workflow tobe executed on the set of servers corresponding to authorization workersystem 120. In one example, system 120 first receives the signedmanifest corresponding to the recurring workflow that is to be executedon the set of target servers. This is indicated by block 270 in the flowdiagram of FIG. 5.

Authorization worker system 120 then determines, whether manifest 180was signed with a signing certificate corresponding to the environmentwhere system 120 resides (e.g., whether the signing certificate istrusted by the environment/workload corresponding to authorizationworker system 120). This is indicated by block 272. If not, then itdetermines that the workflow in manifest 180 is unauthorized. This isindicated by block 274.

However, if, at block 272, system 120 determines that manifest 180 wasindeed signed with the appropriate environment-specific signingcertificate, then it examines the authorization token to determinewhether it was generated based upon the particular workflow contained inthe manifest. This is indicated by block 276. If not, then again system120 determines that the workflow is unauthorized.

However, if, at block 276, it is determined that the authorization tokenwas generated for the workflow represented in the manifest 180, thensystem 120 determines whether the token was generated based upon theidentified set of target machines that are to run the workflow. This isindicated by block 278. If not, then, again, the workflow isunauthorized. However, if, at block 278, it is determined that the tokenwas generated based on the identified target machines, thenauthorization worker system 120 determines whether the token is valid(e.g., whether it was generated based upon the time identified in themanifest during which the workflow is to be executed). This is indicatedby block 280. Again, if the token was not generated based upon thedesired execution time, then the workflow is deemed to be unauthorized.However, if, at block 280, it is determined that the token was generatedbased upon the correct execution time, then authorization worker system120 authorizes execution of the workflow identified in manifest 180.This is indicated by block 282.

It will also be noted that the steps of determining whether theauthorization token was generated based on the “what (which workflow)”,“where” and “when” values can be performed separately by separate piecesof logic, or all at once using one combined algorithm or set of logic.All of these scenarios are contemplated herein.

It can thus be seen that even if the authorization token issurreptitiously obtained, it only authorizes a desired, specificworkflow instance, at a desired target location, during a desired time.Thus, surreptitiously obtaining the authorization token does not help insurreptitiously running any other workflows or accessing any otherenvironments or target machines during any other time period.

It will be noted that the above discussion has described a variety ofdifferent systems, components and/or logic. It will be appreciated thatsuch systems, components and/or logic can be comprised of hardware items(such as processors and associated memory, or other processingcomponents, some of which are described below) that perform thefunctions associated with those systems, components and/or logic. Inaddition, the systems, components and/or logic can be comprised ofsoftware that is loaded into a memory and is subsequently executed by aprocessor or server, or other computing component, as described below.The systems, components and/or logic can also be comprised of differentcombinations of hardware, software, firmware, etc., some examples ofwhich are described below. These are only some examples of differentstructures that can be used to form the systems, components and/or logicdescribed above. Other structures can be used as well.

The present discussion has mentioned processors and servers. In oneembodiment, the processors and servers include computer processors withassociated memory and timing circuitry, not separately shown. They arefunctional parts of the systems or devices to which they belong and areactivated by, and facilitate the functionality of the other componentsor items in those systems.

Also, a number of user interface displays have been discussed. They cantake a wide variety of different forms and can have a wide variety ofdifferent user actuatable input mechanisms disposed thereon. Forinstance, the user actuatable input mechanisms can be text boxes, checkboxes, icons, links, drop-down menus, search boxes, etc. They can alsobe actuated in a wide variety of different ways. For instance, they canbe actuated using a point and click device (such as a track ball ormouse). They can be actuated using hardware buttons, switches, ajoystick or keyboard, thumb switches or thumb pads, etc. They can alsobe actuated using a virtual keyboard or other virtual actuators. Inaddition, where the screen on which they are displayed is a touchsensitive screen, they can be actuated using touch gestures. Also, wherethe device that displays them has speech recognition components, theycan be actuated using speech commands.

A number of data stores have also been discussed. It will be noted theycan each be broken into multiple data stores. All can be local to thesystems accessing them, all can be remote, or some can be local whileothers are remote. All of these configurations are contemplated herein.

Also, the figures show a number of blocks with functionality ascribed toeach block. It will be noted that fewer blocks can be used so thefunctionality is performed by fewer components. Also, more blocks can beused with the functionality distributed among more components.

FIG. 6 is a block diagram of architecture 100, shown in FIG. 1, exceptthat its elements are disposed in a cloud computing architecture 500.Cloud computing provides computation, software, data access, and storageservices that do not require end-user knowledge of the physical locationor configuration of the system that delivers the services. In variousembodiments, cloud computing delivers the services over a wide areanetwork, such as the internet, using appropriate protocols. Forinstance, cloud computing providers deliver applications over a widearea network and they can be accessed through a web browser or any othercomputing component. Software or components of architecture 100 as wellas the corresponding data, can be stored on servers at a remotelocation. The computing resources in a cloud computing environment canbe consolidated at a remote data center location or they can bedispersed. Cloud computing infrastructures can deliver services throughshared data centers, even though they appear as a single point of accessfor the user. Thus, the components and functions described herein can beprovided from a service provider at a remote location using a cloudcomputing architecture. Alternatively, they can be provided from aconventional server, or they can be installed on client devicesdirectly, or in other ways.

The description is intended to include both public cloud computing andprivate cloud computing. Cloud computing (both public and private)provides substantially seamless pooling of resources, as well as areduced need to manage and configure underlying hardware infrastructure.

A public cloud is managed by a vendor and typically supports multipleconsumers using the same infrastructure. Also, a public cloud, asopposed to a private cloud, can free up the end users from managing thehardware. A private cloud may be managed by the organization itself andthe infrastructure is typically not shared with other organizations. Theorganization still maintains the hardware to some extent, such asinstallations and repairs, etc.

In the example shown in FIG. 6, some items are similar to those shown inFIG. 1 and they are similarly numbered. FIG. 6 specifically shows thatcomputing systems 102, 104, 106 and 108 can all be located in cloud 502(which can be public, private, or a combination where portions arepublic while others are private). Therefore, users can use user devicesto access at least some of those systems through cloud 502.

FIG. 6 also depicts another example of a cloud architecture. FIG. 6shows that it is also contemplated that some elements of architecture100 can be disposed in cloud 502 while others are not. By way ofexample, data store 154 can be disposed outside of cloud 502, andaccessed through cloud 502. In another example, systems 106 or 108 (orother items) can be outside of cloud 502. Regardless of where they arelocated, they can be accessed directly, through a network (either a widearea network or a local area network), they can be hosted at a remotesite by a service, or they can be provided as a service through a cloudor accessed by a connection service that resides in the cloud. All ofthese architectures are contemplated herein.

It will also be noted that architecture 100, or portions of it, can bedisposed on a wide variety of different devices. Some of those devicesinclude servers, desktop computers, laptop computers, tablet computers,or other mobile devices, such as palm top computers, cell phones, smartphones, multimedia players, personal digital assistants, etc.

Note that other forms of the devices 16 are possible.

FIG. 7 is one example of a computing environment in which architecture100, or parts of it, (for example) can be deployed. With reference toFIG. 7, an example system for implementing some embodiments includes ageneral-purpose computing device in the form of a computer 810.Components of computer 810 may include, but are not limited to, aprocessing unit 820 (which can comprise processors or servers fromprevious FIGS.), a system memory 830, and a system bus 821 that couplesvarious system components including the system memory to the processingunit 820. The system bus 821 may be any of several types of busstructures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. By wayof example, and not limitation, such architectures include IndustryStandard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus,Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA)local bus, and Peripheral Component Interconnect (PCI) bus also known asMezzanine bus. Memory and programs described with respect to FIG. 1 canbe deployed in corresponding portions of FIG. 7.

Computer 810 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 810 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media is different from, anddoes not include, a modulated data signal or carrier wave. It includeshardware storage media including both volatile and nonvolatile,removable and non-removable media implemented in any method ortechnology for storage of information such as computer readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canbe accessed by computer 810. Communication media typically embodiescomputer readable instructions, data structures, program modules orother data in a transport mechanism and includes any informationdelivery media. The term “modulated data signal” means a signal that hasone or more of its characteristics set or changed in such a manner as toencode information in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer readable media.

The system memory 830 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 831and random access memory (RAM) 832. A basic input/output system 833(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 810, such as during start-up, istypically stored in ROM 831. RAM 832 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 820. By way of example, and notlimitation, FIG. 7 illustrates operating system 834, applicationprograms 835, other program modules 836, and program data 837.

The computer 810 may also include other removable/non-removablevolatile/nonvolatile computer storage media. By way of example only,FIG. 7 illustrates a hard disk drive 841 that reads from or writes tonon-removable, nonvolatile magnetic media, and an optical disk drive 855that reads from or writes to a removable, nonvolatile optical disk 856such as a CD ROM or other optical media. Other removable/non-removable,volatile/nonvolatile computer storage media that can be used in theexemplary operating environment include, but are not limited to,magnetic tape cassettes, flash memory cards, digital versatile disks,digital video tape, solid state RAM, solid state ROM, and the like. Thehard disk drive 841 is typically connected to the system bus 821 througha non-removable memory interface such as interface 840, and optical diskdrive 855 are typically connected to the system bus 821 by a removablememory interface, such as interface 850.

Alternatively, or in addition, the functionality described herein can beperformed, at least in part, by one or more hardware logic components.For example, and without limitation, illustrative types of hardwarelogic components that can be used include Field-programmable Gate Arrays(FPGAs), Program-specific Integrated Circuits (ASICs), Program-specificStandard Products (ASSPs), System-on-a-chip systems (SOCs), ComplexProgrammable Logic Devices (CPLDs), etc.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 7, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 810. In FIG. 7, for example, hard disk drive 841 is illustratedas storing operating system 844, application programs 845, other programmodules 846, and program data 847. Note that these components can eitherbe the same as or different from operating system 834, applicationprograms 835, other program modules 836, and program data 837. Operatingsystem 844, application programs 845, other program modules 846, andprogram data 847 are given different numbers here to illustrate that, ata minimum, they are different copies.

A user may enter commands and information into the computer 810 throughinput devices such as a keyboard 862, a microphone 863, and a pointingdevice 861, such as a mouse, trackball or touch pad. Other input devices(not shown) may include a joystick, game pad, satellite dish, scanner,or the like. These and other input devices are often connected to theprocessing unit 820 through a user input interface 860 that is coupledto the system bus, but may be connected by other interface and busstructures, such as a parallel port, game port or a universal serial bus(USB). A visual display 891 or other type of display device is alsoconnected to the system bus 821 via an interface, such as a videointerface 890. In addition to the monitor, computers may also includeother peripheral output devices such as speakers 897 and printer 896,which may be connected through an output peripheral interface 895.

The computer 810 is operated in a networked environment using logicalconnections to one or more remote computers, such as a remote computer880. The remote computer 880 may be a personal computer, a hand-helddevice, a server, a router, a network PC, a peer device or other commonnetwork node, and typically includes many or all of the elementsdescribed above relative to the computer 810. The logical connectionsdepicted in FIG. 7 include a local area network (LAN) 871 and a widearea network (WAN) 873, but may also include other networks. Suchnetworking environments are commonplace in offices, enterprise-widecomputer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 810 is connectedto the LAN 871 through a network interface or adapter 870. When used ina WAN networking environment, the computer 810 typically includes amodem 872 or other means for establishing communications over the WAN873, such as the Internet. The modem 872, which may be internal orexternal, may be connected to the system bus 821 via the user inputinterface 860, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 810, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 7 illustrates remoteapplication programs 885 as residing on remote computer 880. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

It should also be noted that the different embodiments described hereincan be combined in different ways. That is, parts of one or moreembodiments can be combined with parts of one or more other embodiments.All of this is contemplated herein.

Example 1 is a computing system, comprising:

token generator logic that generates an authorization tokencorresponding to a recurring workflow to be executed on a capacityserver of a remote computing system, the token generator logicgenerating the authorization token based on the recurring workflow andan identity of the capacity server; and

manifest generator logic that generates a manifest including arepresentation of the recurring workflow and the authorization token fortransmission to the capacity server in the remote computing system.

Example 2 is a computer-implemented method, comprising:

detecting that a recurring workflow is to be executed on a capacityserver of a remote computing system;

generating an authorization token corresponding to the recurringworkflow based on the recurring workflow and an identity of the capacityserver; and

generating a manifest including a representation of the recurringworkflow and the authorization token for transmission to the capacityserver in the remote computing system.

Example 1 is a computing system, comprising:

token generator logic that generates an authorization tokencorresponding to a recurring workflow to be executed on a capacityserver of a remote computing system, the token generator logicgenerating the authorization token based on content of the recurringworkflow and an identity of the capacity server; and

manifest generator logic that generates a manifest including arepresentation of the recurring workflow and the authorization token fortransmission to the capacity server in the remote computing system.

Example 2 is the computing system of any or all previous exampleswherein the token generator logic is configured to generate theauthorization token based on processing steps to be executed inexecuting the recurring workflow.

Example 3 is the computing system of any or all previous exampleswherein the capacity server, on which the recurring workflow is to beexecuted, operates in a computing system environment, and furthercomprising:

manifest signing logic configured to sign the manifest with anenvironment-specific signing certificate that is specific to thecomputing system environment in which the capacity server operates.

Example 4 is the computing system of any or all previous exampleswherein the token generator logic is configured to generate theauthorization token based on a time during which the capacity server isto execute the recurring workflow.

Example 5 is the computing system of any or all previous examples andfurther comprising:

approval logic configured to identify an approval process to be executedto obtain approval for the recurring workflow and to execute theidentified approval process.

Example 6 is the computing system of any or all previous exampleswherein, when the approval logic identifies the approval process as amanual approval process that uses approval from an identified humanapprover, then the approval logic is configured to execute the manualapproval process by sending an approval request to a computing systemcorresponding to the identified human approver, requesting manualapproval from the identified approver.

Example 7 is the computing system of any or all previous exampleswherein the approval logic is configured to identify the human approverby identifying permissions that are needed to approve the recurringworkflow and access role-based security data to identify a role with theneeded permissions and to identify the human approver based on theidentified role.

Example 8 is the computing system of any or all previous exampleswherein, when the approval logic identifies the approval process as anautomated approval process that uses approval from an identifiedautomated approval system, then the approval logic is configured toexecute the automated approval process by sending an approval request tothe identified automated approval system, requesting automated approvalfrom the identified automated approval system.

Example 9 is a computer-implemented method, comprising:

detecting that a recurring workflow is to be executed on a capacityserver of a remote computing system;

generating an authorization token corresponding to the recurringworkflow based on content of the recurring workflow and an identity ofthe capacity server; and

generating a manifest including a representation of the recurringworkflow and the authorization token for transmission to the capacityserver in the remote computing system.

Example 10 is the computer implemented method of any or all previousexamples wherein generating the authorization token comprises:

generating the authorization token based on processing steps to beexecuted in executing the recurring workflow.

Example 11 is the computer implemented method of any or all previousexamples wherein the capacity server, on which the recurring workflow isto be executed, operates in a computing system environment, and furthercomprising:

obtaining an environment-specific signing certificate that is specificto the computing system environment in which the capacity serveroperates; and

signing the manifest with the environment-specific signing certificate.

Example 12 is the computer implemented method of any or all previousexamples wherein generating the authorization token comprises:

generating the authorization token based on a time during which thecapacity server is to execute the recurring workflow.

Example 13 is the computer implemented method of any or all previousexamples and further comprising:

identifying an approval process to be executed to obtain approval forexecution of the recurring workflow; and

executing the identified approval process.

Example 14 is the computer implemented method of any or all previousexamples wherein, when the identified approval process is a manualapproval process that uses approval from an identified human approver,then executing the identified approval process comprises:

sending an approval request to a computing system corresponding to theidentified human approver, requesting manual approval from theidentified approver; and

receiving the requested approval from the computing system correspondingto the identified approver.

Example 15 is the computer implemented method of any or all previousexamples wherein sending the approval request comprises:

identifying the human approver by:

identifying permissions that are needed to approve the recurringworkflow;

accessing role-based security data to identify a role with the neededpermissions; and

identifying the human approver based on the identified role.

Example 16 is the computer implemented method of any or all previousexamples wherein, when the identified approval process is an automatedapproval process that uses approval from an identified automatedapproval system, then executing the approval process comprises:

sending an approval request to the identified automated approval system,requesting automated approval from the identified automated approvalsystem; and

receiving the requested approval from the identified automated approvalprocess.

Example 17 is a computer implemented method, comprising:

receiving a workflow request with a signed manifest at a capacity serverin a computing system environment, the manifest including an indicationof content of a recurring workflow that is to be executed on thecapacity server and an authorization token;

determining whether the recurring workflow is authorized based on theauthorization token by:

determining whether the authorization token was generated based on thecontent of the recurring workflow included in the manifest; and

determining whether the authorization token was generated based on anidentity of the capacity;

if the authorization token was generated based on the content of therecurring workflow included in the manifest and based on the identity ofthe capacity server, then executing the recurring workflow on thecapacity server; and

otherwise, responding to the workflow request indicating that therecurring workflow is not authorized.

Example 18 is the computer implemented method of any or all previousexamples wherein determining whether the authorization token wasgenerated based on the content of the recurring workflow comprises:

determining wherein the authorization token was generated based onprocessing steps to be executed in executing the recurring workflow.

Example 19 is the computer implemented method of any or all previousexamples wherein the manifest is signed with an environment-specificsigning certificate and wherein determining whether the recurringworkflow is authorized further comprises:

determining whether the signing certificate is specific to the computingsystem environment in which the capacity server operates.

Example 20 is the computer implemented method of any or all previousexamples wherein determining whether the authorization token wasgenerated based on the content of the recurring workflow comprises:

determining whether the authorization token is generated based on a timeduring which the capacity server is to execute the recurring workflow.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A computing system, comprising: token generatorlogic that generates an authorization token corresponding to a recurringworkflow to be executed on a capacity server of a remote computingsystem, the token generator logic generating the authorization tokenbased on content of the recurring workflow and an identity of thecapacity server; and manifest generator logic that generates a manifestincluding a representation of the recurring workflow and theauthorization token for transmission to the capacity server in theremote computing system.
 2. The computing system of claim 1 wherein thetoken generator logic is configured to generate the authorization tokenbased on processing steps to be executed in executing the recurringworkflow.
 3. The computing system of claim 1 wherein the capacityserver, on which the recurring workflow is to be executed, operates in acomputing system environment, and further comprising: manifest signinglogic configured to sign the manifest with an environment-specificsigning certificate that is specific to the computing system environmentin which the capacity server operates.
 4. The computing system of claim3 wherein the token generator logic is configured to generate theauthorization token based on a time during which the capacity server isto execute the recurring workflow.
 5. The computing system of claim 4and further comprising: approval logic configured to identify anapproval process to be executed to obtain approval for the recurringworkflow and to execute the identified approval process.
 6. Thecomputing system of claim 5 wherein, when the approval logic identifiesthe approval process as a manual approval process that uses approvalfrom an identified human approver, then the approval logic is configuredto execute the manual approval process by sending an approval request toa computing system corresponding to the identified human approver,requesting manual approval from the identified approver.
 7. Thecomputing system of claim 6 wherein the approval logic is configured toidentify the human approver by identifying permissions that are neededto approve the recurring workflow and access role-based security data toidentify a role with the needed permissions and to identify the humanapprover based on the identified role.
 8. The computing system of claim5 wherein, when the approval logic identifies the approval process as anautomated approval process that uses approval from an identifiedautomated approval system, then the approval logic is configured toexecute the automated approval process by sending an approval request tothe identified automated approval system, requesting automated approvalfrom the identified automated approval system.
 9. A computer-implementedmethod, comprising: detecting that a recurring workflow is to beexecuted on a capacity server of a remote computing system; generatingan authorization token corresponding to the recurring workflow based oncontent of the recurring workflow and an identity of the capacityserver; and generating a manifest including a representation of therecurring workflow and the authorization token for transmission to thecapacity server in the remote computing system.
 10. The computerimplemented method of claim 9 wherein generating the authorization tokencomprises: generating the authorization token based on processing stepsto be executed in executing the recurring workflow.
 11. The computerimplemented method of claim 9 wherein the capacity server, on which therecurring workflow is to be executed, operates in a computing systemenvironment, and further comprising: obtaining an environment-specificsigning certificate that is specific to the computing system environmentin which the capacity server operates; and signing the manifest with theenvironment-specific signing certificate.
 12. The computer implementedmethod of claim 11 wherein generating the authorization token comprises:generating the authorization token based on a time during which thecapacity server is to execute the recurring workflow.
 13. The computerimplemented method of claim 12 and further comprising: identifying anapproval process to be executed to obtain approval for execution of therecurring workflow; and executing the identified approval process. 14.The computer implemented method of claim 13 wherein, when the identifiedapproval process is a manual approval process that uses approval from anidentified human approver, then executing the identified approvalprocess comprises: sending an approval request to a computing systemcorresponding to the identified human approver, requesting manualapproval from the identified approver; and receiving the requestedapproval from the computing system corresponding to the identifiedapprover.
 15. The computer implemented method of claim 14 whereinsending the approval request comprises: identifying the human approverby: identifying permissions that are needed to approve the recurringworkflow; accessing role-based security data to identify a role with theneeded permissions; and identifying the human approver based on theidentified role.
 16. The computer implemented method of claim 13wherein, when the identified approval process is an automated approvalprocess that uses approval from an identified automated approval system,then executing the approval process comprises: sending an approvalrequest to the identified automated approval system, requestingautomated approval from the identified automated approval system; andreceiving the requested approval from the identified automated approvalprocess.
 17. A computer implemented method, comprising: receiving aworkflow request with a signed manifest at a capacity server in acomputing system environment, the manifest including an indication ofcontent of a recurring workflow that is to be executed on the capacityserver and an authorization token; determining whether the recurringworkflow is authorized based on the authorization token by: determiningwhether the authorization token was generated based on the content ofthe recurring workflow included in the manifest; and determining whetherthe authorization token was generated based on an identity of thecapacity; if the authorization token was generated based on the contentof the recurring workflow included in the manifest and based on theidentity of the capacity server, then executing the recurring workflowon the capacity server; and otherwise, responding to the workflowrequest indicating that the recurring workflow is not authorized. 18.The computer implemented method of claim 17 wherein determining whetherthe authorization token was generated based on the content of therecurring workflow comprises: determining wherein the authorizationtoken was generated based on processing steps to be executed inexecuting the recurring workflow.
 19. The computer implemented method ofclaim 17 wherein the manifest is signed with an environment-specificsigning certificate and wherein determining whether the recurringworkflow is authorized further comprises: determining whether thesigning certificate is specific to the computing system environment inwhich the capacity server operates.
 20. The computer implemented methodof claim 17 wherein determining whether the authorization token wasgenerated based on the content of the recurring workflow comprises:determining whether the authorization token is generated based on a timeduring which the capacity server is to execute the recurring workflow.